Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/server/src/terminal/Layers/Manager.test.ts`:
- Around line 295-301: This permission test is flaky on Windows because
chmod(0o000) doesn't reliably block access; guard the check by skipping or
short-circuiting it on Windows (process.platform === 'win32') so
manager.open(openInput({ cwd: blockedCwd })) is not expected to hit the
statFailed branch there; update the test in Manager.test.ts around the
blockedRoot/blockedCwd setup (referencing chmod, blockedRoot, blockedCwd, and
manager.open) to conditionally run the chmod+open+assertion only when not on
Windows (or explicitly skip the test on Windows).

In `@apps/server/src/terminal/Layers/Manager.ts`:
- Around line 1125-1145: When draining events you must detect and drop stale
snapshot results if the session was reset concurrently: inside
drainProcessEvents() capture a stable marker (e.g. const snapshotUpdatedAt =
session.updatedAt or a sessionResetCounter) while inside the sync block where
you build the snapshot, then before persisting/publishing each output event (the
block that returns { type: "output", threadId..., history: ..., data: ... } in
Manager.ts) compare the current session.updatedAt/sessionResetCounter to the
captured snapshot marker and if they differ discard/skip emitting that event.
Apply the same guard to the other output-returning block referenced in the
comment (around the 1180–1192 area) so cleared/closed/restarted sessions do not
re-emit pre-reset history.
- Around line 1628-1639: In the open() branch that handles liveSession.status
=== "exited" || "error" (in Manager.ts), do not clear liveSession.history or
persist an empty string: only update liveSession.runtimeEnv (and any
non-transcript runtime metadata) but leave liveSession.history,
pendingHistoryControlSequence, pendingProcessEvents, pendingProcessEventIndex,
and processEventDrainRunning intact and do not call persistHistory with "" —
preserve the transcript for cached exited/error sessions; keep restart() as the
existing destructive path that clears history.

In `@apps/web/src/orchestrationEventEffects.ts`:
- Around line 32-46: The threadLifecycleEffects.set(...) calls for
"thread.created" and "thread.deleted" are overwriting prior entries for the same
event.payload.threadId; change them to merge with any existing entry instead of
replacing it: read existing entry
(threadLifecycleEffects.get(event.payload.threadId) || {}), produce a new object
that preserves existing boolean flags and applies the new ones (e.g.,
existingFlag || newFlag for flags that should persist, or explicitly set/remove
where appropriate), then call threadLifecycleEffects.set(threadId,
mergedObject); update both the "thread.created" and "thread.deleted" handlers to
use this merge logic so a replay batch that contains both events keeps all
intended lifecycle flags.

In `@apps/web/src/orchestrationRecovery.ts`:
- Around line 91-96: completeSnapshotRecovery currently uses Math.max when
setting state.latestSequence which can skip replaying deltas; update the
function so state.latestSequence is assigned the snapshotSequence directly
(state.latestSequence = snapshotSequence) and then ensure
state.highestObservedSequence is at least the snapshot by using
state.highestObservedSequence = Math.max(state.highestObservedSequence,
snapshotSequence); keep state.bootstrapped = true, state.inFlight = null, and
return shouldReplayAfterRecovery() as before.

In `@apps/web/src/routes/__root.tsx`:
- Around line 303-306: When getSnapshot() fails the catch block currently calls
recovery.failSnapshotRecovery(), which permanently prevents bootstrap and causes
later "defer" events to be dropped; instead remove or avoid calling
recovery.failSnapshotRecovery() in that catch so bootstrapped stays false and
the system can retry, and modify the deferred-event path (the handler that
classifies events as "defer") to trigger a retry of the bootstrap recovery
(e.g., call a retry/startSnapshotRecovery method) when bootstrapped is false;
reference getSnapshot(), the bootstrapped flag, and
recovery.failSnapshotRecovery()/the recovery retry/start method to implement
this behavior so deferred events cause an automatic re-attempt of snapshot
recovery.

In `@apps/web/src/session-logic.ts`:
- Around line 898-919: The code can return a fallbackMatch even when the turn
time window is inverted (completedAt < startedAt); before iterating
timelineEntries (after computing turnStartedAt and turnCompletedAt from
latestTurn.startedAt/completedAt), add a guard that returns null if
turnCompletedAt < turnStartedAt to prevent anchoring to an invalid window; this
touches the variables turnStartedAt, turnCompletedAt, latestTurn, and the
existing fallback/inRangeMatch logic so the rest of the loop can assume a valid
time range.

In `@apps/web/src/store.test.ts`:
- Around line 70-94: makeEvent() hard-codes aggregateKind as "thread", which
mislabels project events; change makeEvent (and its aggregateKind assignment) to
derive aggregateKind from the payload or use overrides.aggregateKind when
provided — e.g., if payload has projectId set aggregateKind to "project", if
payload has threadId set it to "thread", and fall back to
overrides.aggregateKind (or a sensible default) so project.* events have the
correct aggregateKind in the returned Extract<OrchestrationEvent, { type: T }>
object.

In `@apps/web/src/store.ts`:
- Around line 145-169: mapThread currently copies full arrays from
OrchestrationThread (messages, proposedPlans, checkpoints -> turnDiffSummaries,
activities), which bypasses the collection caps applied by incremental handlers;
update mapThread to apply the same caps before mapping (e.g., cap messages
before mapping with mapMessage, cap proposedPlans before mapProposedPlan, cap
checkpoints before mapTurnDiffSummary, and cap activities) so bootstrap/recovery
via syncServerReadModel() cannot reintroduce unbounded arrays; locate mapThread
and apply the same truncation logic used by the incremental handlers to those
fields (messages, proposedPlans, checkpoints/turnDiffSummaries, activities)
while preserving the existing mapping functions.

In `@apps/web/src/uiStateStore.ts`:
- Around line 83-90: The code treats an empty array in
parsed.expandedProjectCwds as “no preference” which prevents persisting a true
“collapse all”; change the existence checks to distinguish between
undefined/null and an explicitly empty array by testing
Array.isArray(parsed.expandedProjectCwds) (or parsed.expandedProjectCwds !==
undefined) before iterating and populating persistedExpandedProjectCwds so an
empty array is honored, and apply the same fix for parsed.projectOrderCwds ->
persistedProjectOrderCwds (and the similar block around
parsed.expandedProjectCwds/projectOrderCwds at lines ~170-175) so explicit empty
arrays are preserved rather than treated as missing preferences.
- Around line 19-22: PersistedUiState currently only includes
expandedProjectCwds/projectOrderCwds so threadLastVisitedAtById is dropped on
reload; add a threadLastVisitedAtById?: Record<string, number> (or appropriate
map type) to the PersistedUiState interface and update the code that
serializes/deserializes the persisted UI state (the persistence/load and save
routines that read/write PersistedUiState) to read/write
uiState.threadLastVisitedAtById, merging with defaults when the field is missing
so reloads do not reset visit timestamps.

In `@packages/shared/src/KeyedCoalescingWorker.ts`:
- Around line 36-54: processKey currently recursively processes the same key
until idle, allowing a chatty key to monopolize the worker; modify processKey
(and the TxRef.modify block around stateRef/latestByKey/activeKeys) so that
after options.process(key, value) completes you do NOT immediately recurse into
processKey for nextValue — instead, if nextValue is non-null re-enqueue or mark
the key as active again so the next loop/fiber will pick it up (e.g., push
nextValue into the shared queue or update latestByKey and activeKeys
appropriately) and then return to allow other keys to be scheduled; keep
references to processKey, options.process, stateRef, latestByKey and activeKeys
to locate and change the rescheduling logic.

In `@README.md`:
- Around line 11-12: Update the Codex CLI authentication instruction in the
README: replace the incorrect `codex login` command with the correct first-run
invocation `codex` in the bullet that reads "- Codex: install [Codex
CLI](https://github.com/openai/codex) and run `codex login`", leaving the Claude
line unchanged.
- Line 3: Update the README provider list to reflect actual supported providers:
replace the line claiming "currently Codex and Claude" with a comprehensive list
that includes Codex, Claude, Copilot (CopilotModelOptions), Cursor
(CursorModelOptions), and Gemini CLI (GeminiCliModelOptions) and any other
providers referenced in the codebase; ensure the phrasing matches the project
scope (e.g., "Supports Codex, Claude, Copilot, Cursor, Gemini CLI, and more")
and mention bundling where relevant (referencing the Copilot package bundling in
build scripts) so the README accurately mirrors the symbols and features present
in packages/contracts/src/orchestration.ts and the build configuration.
- Line 22: Update the GitHub Releases link in README.md to point to the fork's
releases (change https://github.com/pingdotgg/t3code/releases to
https://github.com/aaditagrawal/t3code/releases) and update the hardcoded
constants in apps/marketing/src/lib/releases.ts (RELEASES_URL and API_URL) to
reference "aaditagrawal/t3code" instead of "pingdotgg/t3code"; modify the string
values for RELEASES_URL and API_URL in that module so the marketing app and
README both direct to the fork's releases endpoint.

---

Outside diff comments:
In `@apps/web/src/components/ChatView.tsx`:
- Around line 3316-3325: The code calls waitForStartedServerThread(nextThreadId)
but ignores its boolean timeout result and always navigates; change the chain to
check the resolved value from waitForStartedServerThread and only set
planSidebarOpenOnNextThreadRef.current = true and call navigate({ to:
"/$threadId", params: { threadId: nextThreadId } }) when the result is true; if
it returns false, avoid navigating (optionally show a retry/notification or
requeue navigation) so the app doesn't route into a thread the local store
doesn't know about. Use the existing symbols waitForStartedServerThread,
nextThreadId, planSidebarOpenOnNextThreadRef, and navigate to implement the
conditional flow.

---

Nitpick comments:
In `@README.md`:
- Around line 42-52: Update the "Some notes" and "If you REALLY want to
contribute still.... read this first" sections to use a consistent, professional
tone: change "very very early" to "in very early stages" or "in early
development", remove the all-caps "REALLY" and ellipses, and replace the mixed
messaging ("We are not accepting contributions yet" followed by an invitation)
with a single clear policy sentence that either temporarily pauses contributions
or explains the preferred path (e.g., "We are not accepting contributions at
this time; please read CONTRIBUTING.md for guidance or join our Discord for
discussion"), while keeping the link to CONTRIBUTING.md and the Discord invite.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/server/src/terminal/Layers/Manager.ts`:
- Around line 1223-1233: stopProcess/close flow currently clears
session.pendingProcessEvents (and resets
session.pendingProcessEventIndex/processEventDrainRunning) before
session.history is persisted, which can drop already-queued output from onData;
before resetting or clearing the queue in modifyManagerState (and the analogous
block at 1417-1420) ensure you synchronously drain/fold any pending "output"
events into session.history (or call the existing drain/fold helper if present)
and advance pendingProcessEventIndex accordingly so history contains all queued
bytes, then clear the queue and reset the drain flags and other fields; update
both the block around modifyManagerState (session.pendingProcessEvents = []) and
the other location mentioned to perform the fold/drain step first.
- Around line 1073-1077: The eviction helper currently treats any session with
status !== "running" as inactive and can prematurely evict sessions in the
"starting" state; update the filter used to build inactiveSessions (the one
operating on state.sessions.values()) to exclude sessions whose status is
"starting" as well (i.e., only consider sessions with status not equal to
"running" AND not equal to "starting"), and apply this same change to the other
occurrences noted (the similar filters around lines 1592-1600 and 1758-1764) so
open()/restart() created sessions aren't evicted before their PTY is tracked.

In `@apps/web/src/orchestrationRecovery.ts`:
- Around line 65-76: The code uses ES2023 Array.prototype.toSorted (seen in
markEventBatchApplied) which will break in older browsers; either add polyfills
via build (configure `@babel/preset-env` in vite config to include core-js
polyfills or use a polyfill plugin) so toSorted is available at runtime, or
replace usages (e.g., in markEventBatchApplied, uiStateStore, terminal-links,
session-logic) with a compatible stable alternative (copy-and-sort using
slice().sort(...)) and update project docs to state ES2023-only browser
requirements if you choose not to polyfill. Ensure the chosen approach is
applied consistently across all files that call toSorted.

In `@apps/web/src/store.ts`:
- Around line 145-170: The mapThread function still returns unbounded arrays for
turnDiffSummaries and activities; apply the same caps used for
messages/proposedPlans by truncating the mapped arrays to the configured limits
(e.g., use .map(mapTurnDiffSummary).slice(-MAX_TURN_DIFF_SUMMARIES) for
turnDiffSummaries and .map(a => ({...a})).slice(-MAX_THREAD_ACTIVITIES) for
activities), ensuring you reference the existing mapTurnDiffSummary function and
the activities mapping to locate and fix the code paths.

---

Duplicate comments:
In `@apps/server/src/terminal/Layers/Manager.test.ts`:
- Around line 432-451: The test currently expects a fresh/empty transcript after
calling manager.open() on an exited session; update assertions to reflect
preserved-history behavior: after emitting data ("old data\n") and exit, calling
manager.open(openInput()) should return an object whose reopened.history still
contains "old data\n" (not ""), ptyAdapter.spawnInputs should not increase
(adjust expected length to reflect no new spawn), and the persisted history file
at historyLogPath(logsDir) (read via readFileString) should still contain the
original transcript; ensure you reference manager.open, restart(),
reopened.history, ptyAdapter.spawnInputs, historyLogPath and readFileString when
making the changes.

---

Nitpick comments:
In `@apps/web/src/components/Sidebar.logic.ts`:
- Around line 452-453: The generic constraint on sortThreadsForSidebar is
redundant because SidebarThreadSortInput already includes Pick<Thread,
"createdAt" | "updatedAt">; simplify the type parameter by removing the explicit
Pick and constrain T only to SidebarThreadSortInput (and any other unique fields
needed) so the declaration becomes clearer and less repetitive while keeping the
same compile-time guarantees for sortThreadsForSidebar.

In `@apps/web/src/store.ts`:
- Around line 238-255: The function rebindTurnDiffSummariesForAssistantMessage
is allocating a new array copy even when no element changed; update it to return
the original turnDiffSummaries reference when changed remains false instead of
returning [...turnDiffSummaries], so keep the current mapping logic that sets
changed and builds nextSummaries, then return nextSummaries if changed is true
otherwise return turnDiffSummaries; references to changed, nextSummaries and
turnDiffSummaries should guide locating the edit.

In `@apps/web/src/uiStateStore.ts`:
- Around line 52-57: The module-level mutable state
(persistedExpandedProjectCwds, hasPersistedExpandedProjectCwds,
persistedProjectOrderCwds, hasPersistedProjectOrderCwds, currentProjectCwdById,
legacyKeysCleanedUp) can leak across SSR/test runs; to fix, move these variables
into the ui state store instance (e.g., inside the createUiStateStore or
UiStateStore class) or add an explicit reset method (resetPersistedState) that
clears the Set/Map/arrays and resets booleans, then call that reset from tests
and on server initialization to guarantee isolation and avoid hydration
mismatches.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/server/src/terminal/Layers/Manager.ts`:
- Around line 1139-1147: The code currently uses session.updatedAt as a guard to
suppress stale outputs but that value is bumped by benign operations
(pollSubprocessActivity(), resize()) and has only millisecond resolution;
introduce a dedicated reset/version marker (e.g., session.resetToken or
session.version) on the Session object, increment or regenerate it whenever the
terminal is cleared/restarted, attach that marker to the outgoing response
objects (replace or add to the returned payload where session.updatedAt is
currently used in the output for functions like the block assembling code, and
the similar blocks referenced around the other occurrences), and update the
consumers/guards to compare the reset/version marker instead of updatedAt so
benign updates and millisecond collisions no longer allow stale drain results
through.

---

Duplicate comments:
In `@apps/server/src/terminal/Layers/Manager.ts`:
- Around line 1223-1233: The change clears pendingProcessEvents and related
drain state before folding queued output into the session history, which can
drop final output; update the modifyManagerState block in Manager.ts (the
stop/close/restart flow around cleanupProcessHandles(session) and
session.process/session.pendingProcessEvents/session.processEventDrainRunning)
to first fold any queued output into the session transcript/history (e.g., call
the existing fold/flush routine or move pendingProcessEvents into history) and
only then clear pendingProcessEvents, reset pendingProcessEventIndex, and set
processEventDrainRunning to false; apply the same fix pattern to the other
similar blocks referenced (around the open()/cwd/env-reset branch and the other
two spots).
- Around line 1073-1075: The current filtering treats transitional statuses
(e.g., "starting", transient "exited" during restart) as evictable and can
remove a session whose PTY is about to be reattached; change the evict logic to
only target truly-terminal statuses by replacing the ad-hoc filter with a
whitelist/utility such as isEvictableSession(session) that checks session.status
against a small set of permanent terminal states (for example only allow
"dead"/"failed"/"terminated"/explicitly final statuses used in this codebase)
and exclude transitional states like "starting" or transient "exited"; update
the three occurrences referenced (the inactiveSessions filter at state.sessions
usage and the other similar blocks) to use this new check and keep names like
startSession and stopProcess in mind so you don't treat briefly-flipped statuses
as evictable.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/web/src/components/ChatView.browser.tsx`:
- Around line 950-951: Do not reset the connection-scoped WebSocket state by
clearing wsClient or rewinding pushSequence during component unmounts; instead
remove the assignments that set wsClient = null and pushSequence = 1 (and the
similar reset at the other location), and if you need per-test rebinding ensure
the existing open socket is rediscoverable by assigning wsClient = client inside
the "message" handler when a reused socket is observed so tests/harness can find
the live client without forcing a reconnect.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/web/src/components/ChatView.browser.tsx`:
- Around line 1958-2006: The skipped test it.skip("keeps the new thread selected
after clicking the new-thread button") was intentionally disabled due to flaky
WS connections caused by fork provider model queries; create a tracking issue to
unskip and re-enable this test once WS stability is improved, include the test
name, why it was skipped (provider model queries flooding WS), steps to
reproduce (mountChatView with UUID_ROUTE_RE flow, clicking new-thread-button,
promoting via promoteDraftThreadViaDomainEvent), and add a TODO comment near the
it.skip referencing the new issue ID so reviewers can find the follow-up.